1. Technical Field of the Invention
This invention relates to telecommunication systems and, more particularly, to a method in a packet data network of negotiating reporting mechanisms for accounting records and reporting accounting records from a Packet Data Service Node (PDSN) to an accounting server.
2. Description of Related Art
The Code Division Multiple Access (CDMA) 2000 Packet Core Network (PCN) is in the development stage. The development forum is called 3GPP2, and the forum has decided to use Internet Engineering Task Force (IETF) protocols to save development time. In particular, the Radius protocol has been specified for transporting accounting records between Network Access Servers (NASs) in serving networks where mobile stations (MSs) are currently operating, and an Authentication, Authorization, and Accounting (AAA) server (i.e., Home Radius Server) which is normally located in the MS""s home network.
xe2x80x9cAccounting recordsxe2x80x9d refers to information that may be used for billing purposes, and relates to the network resources utilized by a particular user during a call. When a user accesses a network and starts using the resources of the network, the network keeps track of what resources are used, for what types of services, and for how long. This information is reported to an accounting server which consolidates the accounting information and prepares it for delivery to a billing system which performs billing settlement procedures. Therefore, from the operator point of view, accounting records are extremely important.
The Radius protocol is not very flexible because it was designed for a stable environment in which non-roaming users are provided with dial-up access to the network. It does not provide the flexibility for a home network to control/determine/negotiate accounting reporting methods that could be used by the local networks for the users of that home network. The 3GPP2 forum, however, is attempting to use Radius in a roaming environment in which a mobile user can roam from one network to another. This requires that the Radius protocol be used to communicate between NASs in serving networks and accounting servers in the mobile user""s home network or in a broker network. There are problems, however, when attempting to use the Radius protocol to send accounting records for mobile users.
In a roaming environment, there are efficiency and reliability problems with the Radius protocol that may cause the loss of some accounting information. The Radius protocol is currently implemented in such a manner that neither the NAS nor the Home Radius Server have any knowledge of how the network passes information from the serving system to the home system. There may be a number of nodes between the NAS and the Home Radius Server, and if these intermediate nodes do not recognize some of the information elements in a message passing through them, the nodes may filter out the unknown elements or discard the entire message. If the message contains accounting information, then the accounting information is lost.
In the 3GPP2 standards, different events are defined that may occur because of user mobility and the wireless nature of the access. Some parameters in the radio access can change, depending on where the user moves. Parameters such as Quality of Service (QoS), for example, may be renegotiated whenever a user moves to a new network. The user zone may change from cell to cell. Operators want to be notified whenever these changes occur because they are potential billing events. In addition, different operators may desire to have different accounting information supplied by the NAS when different events happen. There is currently no way to provide this type of tailored reporting using the standard Radius protocol. In other words, Radius does not provide the flexibility for a home network to negotiate roaming services (for example, accounting) with the local network for its users in a roaming environment.
The operator may also set a particular tariff for a defined time period such as from 1:00 p.m. to 4:00 p.m. After 4:00 p.m., another tariff may be in effect. Therefore, the network starts sending accounting information before 4:00 p.m. to the accounting server, and then starts a whole new accounting session after 4:00 p.m. In the roaming environment, tariff changes can cause a large amount of information to be reported, depending on the degree of mobility of the user and how many networks are sending information at the same time. The Radius protocol was not designed to handle this type of load or this dynamic network environment. In a non-roaming environment, Radius could handle something like a tariff boundary at 4:00 p.m., but the standards bring in many more reportable events due to user mobility.
The reporting requirements also put a lot of requirements on the NAS, in terms of memory capacity and how many messages it must be able to send. The NAS is also known as a Packet Data Service Node (PDSN), and the Radius protocol does not have any methodology for determining whether the PDSN can handle this load. Likewise, there is no guarantee that the accounting server (in the home network, for example) can handle all of the messages that are being sent.
A recent Contribution to the 3GPP2 forum proposed that instead of sending a Radius accounting message to the accounting server every time an accounting event occurs, the accounting information should be retained in the PDSN for a certain amount of time, or until a certain number of messages have been accumulated, and then the information may be sent in a 3GPP2 vendor-specific container attribute to the Home Radius Server. All of the accumulated information is placed in the container attribute.
However, there are several problems with this approach. First, the Radius protocol today cannot guarantee that this information will make it all the way to the Home Radius Server if an intermediate proxy server or broker server does not recognize the container attribute. If a packet contains an attribute that is not recognized, an intermediate server may filter out the packet. Also, the home network server may not recognize the 3GPP2 extension and may disregard the entire message.
In order to overcome the disadvantage of existing solutions, it would be advantageous to have a method of negotiating reporting mechanisms for accounting records and reporting accounting records to an accounting server that is suitable for use in a mobile environment, and guarantees that accounting information is not lost. The present invention provides such a method.
In one aspect, the present invention is a method in a packet data network of negotiating reporting mechanisms for accounting records and sending accounting records from a Packet Data Service Node (PDSN) to an accounting server. The method comprises the steps of determining by the PDSN, a reporting level capability for the accounting server and any intermediate nodes between the PDSN and the accounting server, and sending accounting records from the PDSN to the accounting server in accordance with the determined reporting level capability.
In another aspect, the method of the present invention includes the steps of sending a message from the PDSN to the accounting server, via any intermediate nodes, that includes (a) an attribute indicating that the PDSN can accumulate a plurality of accounting records and send the accumulated accounting records in a container in a single message, and (b) an attribute indicating a plurality of alternative reporting methods that trigger the PDSN to send a container. The accounting server then sends a response message to the PDSN that (a) confirms that the accounting server can receive accounting records in containers, and (b) indicates a preferred reporting method for triggering the PDSN to send a container. The PDSN then sends containers of accounting records to the accounting server in accordance with the reporting method preferred by the accounting server. In an alternative embodiment, the PDSN may send containers of accounting records to the accounting server at a pre-configured interval.